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(57) A communication system for issuing com- 
mands from an initiator to a target, thereby allowing the 
target to write or read out data into/from a memory area 
which the initiator has and exchanging the data. The in- 
itiator transmits read and write commands for the mem- 
ory area to the target so as not to exceed the total 



number of commands which can be held by the target. 
The target holds the received read and write commands, 
holds references to the commands by different queues, 
and independently processes the commands, so that 
the number of the commands to be transmitted can be 
managed efficiently 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The invention relates to communication control 
method and system for connecting equipment such as 
lator (host computer) and target (printer or the like). 



Related Background Art 

[0002]" in recent years, the IEEE1394 interface is be- 
ing used to connect a computer and peripheral equip- 
ment or connect both peripheral equipment. The 
IEEE 1394 interface has a processing speed h.gher than 
L of the hand shaking system such as a centron.es 
interfaceorthe.ikeandc3nperformabidirectiona.com. 

munication. The 1EEE1 394 interface is also an .nterface 
for a memory bus mode, and equipment connected by 
it can read or write data at a designated address from/ 

to partner's equipment. 

[0003] According to IEEE1394, a.though a protocol 
or a physical layer and a link layer to apply * in a w,de 
range is determined, a detailed protocol for each equ.p- 
menUsno,dedded.Therefore,apro.oco.foratransport 

such as SBP (Serial Bus Protocol)-2 or the hke us- 
ing IEEE1394 has been proposed as physical/link lay- 
ers The transport layer is a layer which provides a data 
transfer function for an application. The applicat,ons us- 
ing such a layer can mutually exchange date. 
100041 The SBP-2 protocol is a protocol utilizing a fea- 
ure as a memory bus mode, of IEEE1394, and the n> 
ception side of data can receive the data - accordance 
Jn circumstances of itself. On the other hand a pro- 
tocols other than SBP-2. there are a protocol ^k* can 
transfer data which is asynchronously generated and a 
protlco. which can realize multichannels. However 
such protocols cannot utilize the feature as a memory 
bus model of IEEE1394. That is, in case of a commun.- 
cation between a host and a printer, data transfer cannot 
be performed in accordance with dtc™^«^ 
printer side and the host has to perform the data transfer 
while monitoring a status of the printer. 
[00051 According to SBP-2, in case of transferring da- 
a an operation called "login" is first performed on the 
transmission side, thereby establishing a channel with 
a communication partner. In this instance, the .og.n side 
is called an initiator and the partner side connected to 
the initiator is called a target. The data transfer ,s per- 
formed by reading or writing data from/into a buffer of 
the initiator from the target in accordance with an in- 
struction from the initiator. In such a system, the initiator 
forms an ORB (Operation Request Block) m which an 
address, a size, and the like of the buffer ,n which the 
data to be transmitted has been stored ^ve beenwnt- 
ten and notifies the target of the address of the ORB. 
The target reads out or writes the data from/to the in.t.- 



ator on the basis of the address and size wntten in the 
ORB in accordance with its own circumstances, forms 
a status block after completion of those processes, and 
notifies the initiator of states of the processes, 
s f00061 In case of performing a communication by us- 
ng the SBP-2 protoco. established on IEEE1394. par- 
ticularly, in the case where a data source such as a host 
computer or the like is used as an initiator and ,t is ap- 
plied to a data transfer from the initiator to peripheral 
10 equipment such as a printer apparatus or the like as a 
target, there are the four following problems. 

(Problem 1) A procedure is complicated because of a 
full duplex communication. 



100071 in SBP-2, the data transfer is fundamentally 
managed by the initiator and the target cannot perform 
the asynchronous data transfer to the ,n. .ator. That « 
in SBP-2, when the target wants to transfer data to the 
20 initiator, it sends a data reading request to the initiator 
in an unsolicited status. The initiator forms an ORB in 
response to it and inc.udes the formedORB into theend 
of a list of the pending ORBs (a data transfer request 
from the initiator to the target and the like are included). 
25 Since the ORBs are processed ,n order from , the , heaa. 
the data is transferred from the target to the in.tiator lor 
the first time when the process of the ORB on the m.tiator 
side is progressed and the ORB processes in response 
to the data reading request from the target '"Stead of a 
30 timing when the target issues the reading reques to the 
initiator. That is. in the case where the ^rectiona asyn- 
chronous data transfer cannot be performed and the da- 
'atobetransferredfrom the targetto the initiator « asyn- 
chronously generated, for example, assum.ng that .the 
35 target is a printer, in the case where an error occurs ,n 
the printer, or the like, the data to be transferred imme- 
diately to the initiator cannot be momentarily transmit- 

S>8] Therefore, for example, to immediately send 
« datawhichisasynchronous.ygeneratedfromthepr.nter 

to the host, a login procedure has to be 
using the printer as an initiator and a data transfer in 
which the host computer is used as a target has to be 

« ST*'" a situation such that the host computer and 
theprintermutually login and each of them .sthe m.tiator 
or the target as mentioned above, a process as ar . ini- 
tiator and a process as a target have to be provided for 
both the host computer and the printer. The operation 
so of login has to be also performed by the pnnter. In a pe- 
ripheral apparatus such as a printerfor Handling an im- 
age, a large amount of memory resources or processor 
resources are consumed for image processes. There- 
fore, costs have to be shaved by simplify.ng a construc- 
55 tion of the apparatuses or resources which are used tor 
applications other than the image processing apphca- 
tion have to be saved as much as possible in order to 
perform the processes promptly. However, as men- 
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tioned above, the more often the processes are execut- 
ed, the larger amount of resources are consumed. This 
is contrary to the purpose of shaving costs and realiza- 
tion of a high efficiency of processes. 
[0010] As for the relation between the host computer 
and the printer, data flowing in each direction is corre- 
lated as a relation between print data and a processing 
situation of it. However, if a channel is set by an inde- 
pendent login with respect to each direction, those data 
and response have to be mutually concerned and it is 
necessary to newly add a processing procedure for such 
a purpose. 

[0011] " As mentioned above, it is not proper to apply 
IEEE1394 and SBP-2 to the communication between 
the host computer and the printer apparatus as they are. 
It is difficult to reduce the resources necessary for each 
apparatus and improve the efficiency. 

(Problem 2) Multichannels cannot be realized. 

[0012] In recent years, a hybrid apparatus in which 
various functions are combined as peripheral appara- 
tuses is being used. For example, there is a digital hybrid 
apparatus or the like such that a facsimile apparatus is 
used as a scanner unit apparatus, a printer unit appa- 
ratus, and a facsimile and can be used from the host 
computer or the like. When such a hybrid apparatus is 
used, if a communication is performed through a plural- 
ity of independent channels every unit apparatus func- 
tion, a plurality of functions can be simultaneously used. 
[0013] In SBP-2, however, since the multichannels 
cannot be provided, it is difficult to simultaneously use 
such unit apparatus functions. 

(Problem 3) It is impossible to cope with a bus reset. 

[0014] In IEEE1394, a bus reset occurs when a status 
change which becomes a cause of a change of a net- 
work construction such that new equipment is connect- 
ed to a 1 394 serial bus or the equipment is disconnected 
or a power source of the connected equipment is turned 
on or off occurs. The bus reset occurs when a node 
which detects the status change as mentioned above 
on the bus transmits a bus resetting signal onto the bus. 
The generated bus resetting signal is transmitted from 
one node to another. When all nodes on the network 
receive the bus resetting signal, a series of operations 
for the bus reset is performed in each node. 
[0015] As mentioned above, the bus reset occurs 
asynchronously with the process in a node on a network. 
Even in case of a node which is not concerned with a 
node which becomes a cause of the bus reset with re- 
spect to the application, if the bus reset has once oc- 
curred, a bus resetting process has to be performed. In 
the bus resetting step, in the node which performs a 
communication by SBP-2, the set connection is discon- 
nected. Even if it is re-connected, a guarantee such that 
the process can be continued from the state just before 
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the bus reset is not given. 

[0016] Since the initiator transmits commands to the 
target so as not to exceed the number of commands in 
each queue, there is a case where commands assured 
5 in the queues which are not used are in vain. 

SUMMARY OF THE INVENTION 

[0017] The invention is made in consideration of the 
10 above conventional technique and it is a concern of the 
invention to provide communication control method and 
apparatus which enables a full duplex communication 
(mutually asynchronous bidirectional communication) 
and can efficiently use resources such as processes 
*5 and memories necessary for exchanging data and pro- 
vide a printing apparatus using such method and appa- 
ratus. 

[0018] Another concern of the invention is to provide 
communication control method and apparatus which re- 
20 alize multichannels and provide a printing apparatus us- 
ing such method and apparatus. 

[0019] Still another concern of the invention is to pro- 
vide communication control method and apparatus 
which guarantee the continuation of processes from a 
25 state just before a bus reset even if the bus reset occurs 
and provide a printing apparatus using such method and 
apparatus. 

[0020] A further concern of the invention is to provide 
a communication control method, a communication sys- 

30 tern, a print control apparatus, a printing apparatus, a 
host apparatus, a peripheral apparatus, and a storage 
medium which can efficiently use resources by unitarily 
managing the number of commands which can be trans- 
mitted from an initiator to a target instead of Managing 

35 it every queue of the target. 

[0021] Yet another concern of the invention is to pro- 
vide a communication control method, a communication 
system, a print control apparatus, a printing apparatus, 
a host apparatus, a peripheral apparatus, and a storage 

40 medium, in which an initiator dynamically performs an 
allocation to all of command pool areas of a target in a 
multiplex path by queues, thereby improving a commu- 
nicating efficiency and a resource using efficiency of the 
target, and the number of command pool areas of the 

45 target is increased or decreased in accordance with the 
number of queues which are used for connection, there- 
by improving the resource using efficiency of.the target. 
[0022] According to an aspect of the invention, there 
is provided a communication control method of issuing 

50 commands from an initiator to a target, thereby allowing 
the target to write or read out data into/from a memory 
area which the initiator has and exchanging the data, 
wherein the initiator transmits read/write commands for 
the memory area to the target so as not to exceed the 

55 total number of commands which can be held in the tar- 
get, and the target holds the received read/write com- 
mands, holds references to the commands by different 
queues, and individually processes them. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0023] 

Fig. 1 is a block diagram of a target (printer); 
Fig. 2 is a block diagram of an initiator (host com- 
puter); 

Fig. 3 is a flowchart for a processing procedure 
when a data transfer request is generated by a cli- 
ent of the initiator; 

Fig. 4 is a flowchart for a processing procedure 
when an end-of-process notice is received from 
SH^T-2 by the client of the initiator, 
Figs. 5A, 5B and 5C are flowcharts for a write func- 
tion and a read function which are executed by an 
SHPT-2 processor of the initiator and called from 
the client and a flowchart for a managing procedure 
of an I/O request queue which is executed by the 
SHPT-2 processor of the initiator 
Fig. 6 is a flowchart for a processing procedure 
which is executed by the SHPT-2 processor of the 
initiator when a status block is received; 
Figs. 7A and 7B are diagrams showing a general 
format of an ORB; 

Fig. 8 is a diagram showing a format of a write com- 
mand ORB; 

Fig. 9 is a diagram showing a format of a read com- 
mand ORB; 

Fig. 10 is a diagram showing a format of a connec- 
tion command ORB; 

Fig. 11 is a diagram showing a format of a discon- 
nection command ORB; 

Fig. 12 is a diagram showing a format of a query 
command ORB; 

Fig. 13 is a diagram showing a general format of a 
status block; 

Fig. 14 is a diagram showing a format of a connec- 
tion status block; 

Fig. 15 is a diagram showing a format of a query 
status block; 

Fig. 16 is a flowchart for a processing procedure 
which is executed by the SHPT-2 processor of the 
initiator in response to an opening request from the 
client; 

Fig. 1 7 is a flowchart for a processing procedure for 
a connecting request of the target; 
Fig. 18 is a flowchart for a recovery processing pro- 
cedure which is executed by the SHPT-2 processor 
of the initiator just after a bus reset; 
Fig. 19 is a flowchart for a processing procedure 
which is executed by a fetch agent of the target 
when writing is performed to a doorbeil register or 
an ORB pointer; 

Fig. 20 is a flowchart for a processing procedure 
which is executed by an execution agent of the tar- 
get; 

Fig. 21 is a flowchart for a processing procedure 
which is executed by the SHPT-2 processor of the 



initiator in response to a closing request from the 
client; 

Fig. 22 is a flowchart for a processing procedure for 
a disconnecting request of the target; 
Fig. 23 is a diagram showing a format of a discon- 
nection command ORB according to the second 
embodiment; 

Fig. 24 is a constructional diagram of hardware of 
a printer system using the IEEE1394 interface; and 
Fig. 25 is a diagram showing a format of a prefetch 
pool capacity change command. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

(First embodiment) 

[0024] A printer system in which a host computer and 
a printer are connected by IEEE1394 and an SBP-2 pro- 
tocol constructed on IEEE1 394 is used and a data trans- 
fer is performed in accordance with a protocol (herein- 
after, referred to as SHPT-2) according to the invention 
will now be described as a first embodiment of the in- 
vention. Fig. 24 is a constructional diagram of hardware 
in the printer system. 

< Hardware construction of system > 

[0025] In Fig. 24, a host computer 200 has a CPU 1 
for executing processes of a document in which a figure, 
an image, characters, a table (including a spreadsheet 
or the like), and the like mixedly exist on the basis of a 
document processing program or the like stored in a pro- 
gram ROM of an ROM 3. The CPU 1 integratedly con- 
trols each device connected to a system bus 4. A control 
program and the like of the CPU 1 are stored in the pro- 
gram ROM of the ROM 3. Font data and the like which 
is used in the document process is stored in a font ROM 
of the ROM 3. Various data which is used when the doc- 
ument process or the like is executed is stored in a data 
ROM of the ROM 3. An RAM 2 functions as a main mem- 
ory, a work area, or the like of the CPU 1. 
[0026] The programs can be also stored in the RAM 
2. A transmission data buffer or a system memory to 
store an ORB is assured in the RAM 2. 
[0027] A keyboard controller (KBC) 5 controls a key 
input from a keyboard 9 or a pointing device (not shown). 
A CRT controller (CRTC) 6 controls a display on a CRT 
display (CRT) 10. A memory controller (MC) 7 controls 
an access to an external memory 11 such as hard disk 
(HD), floppy disk (FD), or the like to store a boot pro- 
gram, various applications, font data, a user file, an edit 
file, and the like. A 1 394 interface 8 is connected to a 
printer 100 and executes a communication control proc- 
ess of a communication with the printer 100 in accord- 
ance with the IEEE 1394 standard. For example, the 
- CPU 1 executes a developing (rasterizing) process of 
an outline font into a display information RAM set on the 
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RAM 2. thereby enabling WYSIWYG on the CRT 10. 
The CPU 1 opens various registered windows on the 
basis of commands instructed by a mouse cursor or the 
like (not shown) on the CRT 10 and executes various 
data processes. 5 
[0028] In the printer 1 00, a printer CPU 1 2 integratedly 
controls accesses to various devices connected to a 
system bus 1 5 on the basis of a control program stored 
in a program ROM of an ROM 13, a control program 
stored in an external memory 1 4, or the like, and outputs 10 
an image signal as output information to a printing unit 
(printer engine) 17 connected through a printing unit in- 
terface*i(engine interface) 16. Various agents, which will 
be explained hereinlater, a control program for the CPU 
12 to realize image processes, and the like are stored *5 
in the program ROM of the ROM 1 3. Font data and the 
like which are used when the output information is 
formed are stored in a font ROM of the ROM 1 3. In case 
of a printer without the external memory 14 such as a 
hard disk or the like, information and the like which are 20 
used on the host computer are stored in a data ROM of 
the ROM 13. The CPU 12 can execute a communicating 
process of a communication with the host computer 
through a 1 394 interface 1 8 and notify the host computer 
200 of information or the like in the printer. 25 
[0029] An RAM 19 functions as a main memory, a 
work area, or the like of the CPU 12 and is constructed 
so that a memory capacity can be expanded by an op- 
tion RAM which is connected to an expanding port (not 
shown). The RAM 19 is used as an output information 30 
rasterizing area, an environmental data memory area, 
an NVRAM, or the like. An access to the external mem- 
ory 14 such as hard disk (HD), IC card, or the like men- 
tioned above is controlled by a memory controller (MC) 
20. The external memory 1 4 is connected as an option 35 
and stores font data, an emulation program, form data, 
and the like. Switches for operation, an LED display, and 
the like are arranged on an operation panel 1002. The 
number of external memories is not limited to 1 . The ap- 
paratus can be also constructed in a manner such that to 
at least one or more external memories are provided 
and an option font card in addition to built-in fonts and 
a plurality of external memories in which programs to 
interpret printer control languages of different language 
systems have been stored can be connected. Further, 45 
the apparatus can have an NVRAM (not shown) and 
store printer mode set information from the operation 
panel 1002. 

[0030] Although not shown, a finisher having a stapler 
function, a sorter function, and the like can be also con- so 
nected. 

Construction of Initiator 

[0031] In the foregoing hardware construction, Figs. 55 
1 and 2 show communication systems in which the print- 
er 100 is used as a target and the host computer 200 is 
used as an initiator. In the embodiment, those construc- 
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tions are realized by executing programs by CPUs in the 
host computer and the printer, respectively. First, the in- 
itiator in Fig. 2 will be described. 

[0032] In Fig. 2, in the host computer as an initiator, a 
client 206 such as a printer driver or the like issues a 
data transfer request for a printer through an SHPT-2 
processor 201 and receives a response from the printer. 
[0033] The SHPT-2 processor 201 manages I/O re- 
quest queues and ORBs which are formed in the system 
memory. The client 206 comprises one or a plurality of 
client processes. The I/O request command from each 
client process is queued into each I/O request queue 
which is used for communication of each client process. 
Although four I/O request queues are shown as an ex- 
ample in the diagram, the number of I/O request queues 
is not limited to 4. The I/O request queue is dynamically 
prepared at the time of a connection of a communication 
of each client process. One or a plurality of I/O request 
queues are used for communication of each client proc- 
ess. 

[0034] In the example shown in the diagram, two I/O 
request queues 202a and 202b are used for communi- 
cation of a client process 206a. A write request com- 
mand from the client process 206a is queued into the I/ 
O request queue 202a. A read request command from 
the client process 206a is queued into the I/O request 
queue 202b. A state where an asynchronous full duplex 
communication is performed by those two I/O request 
queues is shown. Similarly, an I/O request queue 202c 
is used for communication of a client process 206b. A 
write request command is queued into the I/O request 
queue 202c and a unidirectional communication is per- 
formed. An I/O request queue 202d is used for commu- 
nication of a client process 206c. A state where a syn- 
chronous semi duplex communication is performed by 
queueing one or both of the write request command and 
read request command into the I/O request queue 202d 
is shown. 

[0035] ORB is a block in which an address, a size, 
and the like of a data buffer which are sent from the host 
computer as an initiator to the printer as a target or from 
the printer to the host computer have been stored. The 
blocks are sequentially linked to an ORB list 204 from 
the head ORB. With respect to the ORB, there are the 
following processing rules. 

(1) ORBs are formed in order from a command ex- 
tracted from the head of each I/O request queue 
and included to the end of the ORB list. The order 
of including the commands to the end of the ORB 
list is not particularly limited. It is also possible to 
allocate a priority order to each I/O request queue 
and allocate the command at the head of a specific 
I/O request queue preferentially to the end of the 
ORB list. 

(2) The ORBs are sequentially fetched from the 
head of the ORB list. When a completion notice 
(status block) is received, the ORB corresponding 
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to the status is removed from the ORB list. 
(3) The upper limit of the number of ORBs which 
are linked is the same as a capacity (also including 
commands which are being processed as well) of a 
prefetch pool in a target, which will be explained 
herein) ater. 

[0036] By the above items (1 ) and (2), it is guaranteed 
that the I/O request of each I/O request queue is issued 
to the target in generating order in each I/O request. By 
the above item (3), it is guaranteed that the I/O request 
in the ORB list is sent to the target. To realize the item 
(3), the'feHPT-2 processor 201 prepares one counter for 
each request queue and one counter for the prefetch 
pool, respectively. 

[0037] A counterfor each I/O request queue is a coun- 
ter called Current-QUE. In the example shown in the di- 
agram, four Current-QUE counters 203a, 203b, 203c, 
and 203d are shown for four I/O request queues. In each 
Current-QUE counter, the number of reserved areas in 
the prefetch pool allocated to the respective I/O request 
queues is held in the denominator (right side). The 
number of commands (in the current ORB list) belonging 
to the I/O request queue is held in the numerator (left 
side). 

[0038] The example in the diagram shows a state 
where the number of reserved areas in the prefetch pool 
allocated to the I/O request queues is equal to "1" and 
the numbers of commands (in the current ORB list) be- 
longing to the I/O request queues 202a, 202b, 202c, and 
202d are equal to "3", "I", "0", and "2", respectively. 
[0039] A counter for the prefetch pool is a counter 
203e called Current-POOL The total number ("1 + 1 + 
1 + 1** = "4") of the numbers of reserved areas in the I/ 
O request queues is subtracted from the total number 
"10" of areas in the prefetch pool and a resultant value 
"6" is set to the denominator (right side). This counter 
indicates the number of free areas in the prefetch pool 
other than the reserved areas allocated to the I/O re- 
quest queues. 

[0040] The number "3" of areas which can be lent to 
the request queues is set to the numerator (left side). 
Specifically speaking, among the values of the counters 
203a to 203d in which the numerator is larger than the 
denominator, in this case, the values of (the numerator 
- the denominator), namely, (3 - 1 = 2, 2 - 1 = 1) of the 
counters 203a and 203d are calculated. A value "3" ob- 
tained by adding "2" and "1" calculated from the number 
"6" of free areas in the prefetch pool other than the re- 
served areas allocated to the I/O request queues is sub- 
tracted from "6" of the denominator. A resultant value 
"3" is set to the numerator. 

[0041] The example in the diagram shows a state 
where the number of free areas in the prefetch pool oth- 
er than the reserved areas allocated to the I/O request 
queues is equal to "6". 

[0042] The total number of areas in the prefetch pool 
is held by the equipment as a target. This value is read 



out from the target at the time of login or the like and 
stored into the initiator. 

[0043] The example in the diagram shows a state 
where the total number of areas in the prefetch pool is 

5 equal to "10". The number (in the current ORB list) in 
the Current-QUE counter associated with the I/O re- 
quest queue is increased or decreased in accordance 
with the formation and deletion of the ORB. 
[0044] Upon formation of the ORB, if the number (in 

10 the current ORB list) in the Current-QUE counter does 
not exceed the number of reserved areas in the prefetch 
pool allocated to the I/O request queues at the initial 
stage, the number in the Current-QUE counter is in- 
creased and the ORB is added into the ORB list. Other- 

15 wise, a check is made to see if the number in the Cur- 
rent-POOL counter is equal to or larger than "1". If it is 
equal to or larger than "1", the number in the Current- 
POOL counter is decreased, the number in the Current- 
QUE counter is increased, and the ORB is added into 

20 the ORB list. If the number in the Current-POOL counter 
is already equal to "0", the ORB is not added into the 
ORB list. 

[0045] Upon deletion of the ORB, when the number 
(in the current ORB list) in the Current-QUE counter ex- 

25 ceeds the number of reserved areas in the prefetch pool 
allocated to the I/O request queues at the initial stage, 
the number in the Current-POOL counter is increased. 
In any case, the number (in the current ORB list) in the 
Current-QUE counter is reduced. 

30 [0046] When the ORB is formed, a predetermined val- 
ue is written into a register called a doorbell register on 
the target side or the address of the ORB at the head of 
the list is written into a register called an ORB pointer, 
thereby notifying the target of the generation of the ORB. 

35 |f the ORB has already been added to the end of the 
ORB list which is being executed by the target, the pre- 
determined value is written into the doorbell register. 
When the head ORB is newly formed in a state without 
an ORB list, the address is written into the ORB pointer. 

40 This procedure is specified in SBP-2. 

[0047] The SHPT-2 processor 201 includes a status 
FIFO 205. 

[0048] The status received through a 1394 interface 
109 is processed by the SHPT-2 processor 201. The 

45 SHPT-2 processor 201 removes the ORB correspond- 
ing to the received status from the ORB list 204 and re- 
moves the command corresponding to the removed 
ORB from the I/O request queue. 
[0049] The host computer as an initiator has the func- 

50 tional construction as mentioned above. 

Construction of target> 

[0050] Fig. 1 is a block diagram showing a functional 
55 construction of the printer as a target. In Fig. 1 , a door- 
bell register lOla is a register in which a value is written 
by the initiator and shows that the ORB has newly been 
formed. The address of the newly formed ORB is written 
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into an ORB pointer lOlb by the initiator. When the value 
is written into the doorbell register lOla, a fetch agent 
101 reads out the ORB shown by the ORB pointer 
through the 1394 interface 109. An ORB dispatcher 102 
extracts a pointer from a free reference list 104, stores 5 
the command of the ORB read by the fetch agent 101 
into free areas (Fr-1 to Fr-4) in a prefetch pool 103 
shown by the pointer, and connects the pointer to the 
end of the reference queue in accordance with a 
"QueueiD" field, which will be explained hereinlater, of to 
the relevant ORB. 

[0051] The example in the diagram shows a state 
where four reference queues 105a, 105b. 105c, and 
105d exist. The number of reference queues is not lim- 
ited to 4, The reference queues are dynamically pre- *5 
pared when a communication of each client process is 
connected. One or a plurality of reference queues are 
used for communication of each client process. 
[0052] An execution agent 106 fetches the com- 
mands queued into each reference queue from the 20 
head, performs the writing of data into the buffer of the 
initiator, the reading of the data from the buffer of the 
initiator, or the like in accordance with commands, and 
after that, returns a normal status to the host computer. 
[0053] In the execution agent 106, one execution 25 
thread can independently schedule and execute the 
processes for all of the reference queues so as not to 
be blocked by the processes of the other reference 
queues, or the threads can be scheduled and executed 
by another execution thread every reference queue. Or, 30 
a combination of those executing methods can be used. 
The execution agent 106 writes the data into the buffer 
of the initiator designated by a read command in the 
prefetch pool which is referred to by the reference queue 
1 05b in response to a data transfer request from a client 35 
process 108a such as a rasterizer or the like for inter- 
preting, for example, a PDL and forming raster data. 
Since the data transfer request is generated asynchro- 
nously with a write command or a read command from 
the initiator, the initiator always queues the read com- 40 
mand into the prefetch pool which is referred to by the 
reference queue 105b by the read command ORB. The 
target can send the data to the initiator any time so long 
as the read command is queued in the prefetch pool 
which is referred to by the reference queue 1 05b. A bus 45 
interface 110 is an interface for accessing from the print : 
er 1 00 as a target to a desired memory location in a sys- 
tem memory 208 of the host computer 200 as an initia- 
tor. The constructions and operations of the initiator and 
target have been simply described above. The detailed 50 
contents of the ORB will be first explained prior to de- 
scribing them further in detail. 

<Contents of command ORB (Operation Request 

Block)> 55 

[0054] Figs. 7A and 7B are diagrams showing a gen- 
eral construction of the ORB. In Fig. 7A, a "Next_ORB" 



(link) field 301 is a link to the next ORB. 
[0055] When there is not the next ORB, a predeter- 
mined value showing the absence of the next ORB is 
inserted. The head ORB is shown by a predetermined 
address register. 

[0056] A "data_descriptor" field 302 shows an ad- 
dress in a data buffer. A "d" (direction) field 303 shows 
a data transfer (0: write) from the host computer to the 
printer or a data transfer (1 : read) from the printer to the 
host computer. A "data_size" field 304 indicates a size 
of data buffer shown by the address field 302. The fields 
(also including fields which are not described yet) locat- 
ing above a dotted line in the diagram are the fields 
specified by SBP-2 and fields 305 to 308 which will be 
described from now on are fields which are used for 
processes peculiar to SHPT-2. 

[0057] The "QueuelD" field 305 indicates an ID of a 
reference queue which is used. The "function" field 306 
indicates a kind of ORB as shown in Fig. 7B. OH indi- 
cates the write command. 40H indicates the read com- 
mand. 

[0058] The "seqJD" (sequence ID) field 308 indicates 
a sequential identifier which is allocated every reference 
queue in forming order of the ORBs. In the embodiment, 
the identifier is given so as to increase each time the 
ORB is formed. 

[0059] After the "seq_ID" field increases to the maxi- 
mum value, it is returned to "0" in the next increase. A 
counter which gives a value to the sequence ID field and 
serves as a reference is provided in a region where it is 
not influenced by the bus reset or another obstacle. This 
is because the processes are performed in the target 
while increase performance of the sequence ID is used 
as a prerequisite. Various values are inputted into a con- 
trol block field 309 in accordance with the value in the 
function field 306 or a function which is realized by the 
target for each function. The address and size of the 
buffer are obtained at the time of formation of the ORB 
from the command inputted in the I/O request queue. 
[0060] The contents of the ORB will now be described 
every function. 

(Write command ORB) 

[0061] Fig. 8 shows a write command ORB of a func- 
tion = OH. 

[0062] This command is a command to send the data 
in the designated buffer from the initiator to the target. 
A value in the function field is equal to "OH". The T (tag) 
bit 307 shows a data tag. 

(Read command ORB) 

[0063] Fig. 9 shows a read command ORB of the func- 
tion = 40H. 

[0064] This command is a command to read out the 
data from the target by the initiator. A value in the func- 
tion field is equal to 40H. 
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(Connection command ORB) 

[0065] Fig. 10 shows a connection command ORB of 
the function = C1H. This command is issued for a refer- 
ence queue for a connection service in which "QueuelD" 
= 0 and used to open a new connection and obtain an 
ID of a reference queue which is used for such connec- 
tion. An ID of a service of a new connection destination 
is designated in a "ServiceJD" field 309a. Information 
indicating that to which one of the full duplex bidirection, 
unidirection, and semi duplex bidirection the connection 
is set is designated in a "Mode" field 309b. 
[0066] An 1" bit 309e is set to 1 when the initiator re- 
quests an increase in the prefetch pool to the target. 

(Disconnection command ORB) 

[0067] Fig. 11 shows a disconnection command ORB 
of the function = C2H. This command is used to close 
the connection opened by the connection command 
ORB. This command can be issued for the reference 
queue to be closed or can be issued for a reference 
queue for a connection service in which "QueuelD" = 0. 
When this command is issued for a reference queue for 
a connection service in which "QueuelD" = 0, the con- 
nection for the reference queues designated by "Queue- 
IDI" field 309c and "QueuelD2" field 309d is closed. 
When only one reference queue is used for connection, 
0 is designated in the "QueuelD2" field. 



(Query command ORB) 

[0068] Fig. 12 shows a query command ORB of the 
function = COH. This command is used to get a capacity 
of the prefetch pool from the target prior to the commu- 
nication after the login. 

(Status block) 

[0069] Fig. 1 3 shows a format and contents of a status 
which is returned from the target to the initiator. In Fig. 
1 3, since the fields locating above a dotted line are the 
fields specified by SBP-2, they are not described in par- 
ticular. A tag field 404 shows a data tag and is valid only 
in the status for the read command ORB. 
[0070] "SHPT2_status1" and "S HPT2_ statu s2" 
(SHPT-2 status) fields are fields showing an execution 
result status of the command ORB and indicate an error 
when they are other than 0. That is, when the value is 
equal to 0, this means that the processes with respect 
to the command ORB corresponding to such a status 
have been completed. For example, when the corre- 
sponding command ORB is the write command, this 
means that as for the status block in which the SHPT-2 
status is equal to 0, the target reads out all of the data 
from the buffer indicated by the corresponding write 
command ORB and finishes the writing into the buffer 
which the target has. When the value is other than 0, 



this means that a part or all of the processes of the cor- 
responding command ORB are not performed due to the 
error. The initiator which received this error copes with 
the error by notifying the client of the occurrence of the 
5 error, or the like. 

[0071] A "residual" (remain) field 406 shows a resid- 
ual data length excluding a length of data processed for 
the buffer indicated by the ORB. 

10 (Connection status block) 

[0072] Fig. 1 4 shows a status block for the connection 
command ORB of the function = C1H. This block is sent 
from the target to the initiator when the connection corn- 
's mand is finished. The IDs of the reference queues which 
are used for new connection are shown in a "QueuelDI" 
field 407a and a "QueuelD2" field 407b. When a "Mode" 
field of the connection command ORB indicates the uni- 
direction, 0 is returned to "QueuelD2". In case of the 
20 semi duplex, the same ID is returned to "QueuelDV and 
"QueuelD2". In case of the bidirection, different IDs are 
returned to "QueuelDV* and "QueuelD2". A"POOL_lnc" 
field 407c indicates an increase amount of the capacity 
of the prefetch pool of the target. 

25 

(Query status block) 

[0073] Fig. 15 is a status block for the query command 
ORB of the function = COH. This block is sent from the 
30 target to the initiator when the query command is fin- 
ished. The capacity of the prefetch pool of the target is 
returned to an "lnit_POOL" field 407d. 



35 



<Management of ORB? 



[0074] How the ORB is used will now be described on 
the basis of the constructions of the initiator and target 
described above and the constructions of the command 
ORB and status block. 

40 [0075] Aflowof commands among the initiator, target, 
and clients will now be described with reference to Figs. 
1 and 2. Explanation will now be made on the assump- 
tion that the request queue A 202a and reference queue 
A 105a are used for the data transfer from the initiator 

45 side to the target side and the request queue B 202b 
and reference queue B 1 05b are used for the data trans- 
fer from the target side to the initiator side. 
[0076] When a data transfer request from the client of 
the initiator is issued, the client includes the write com- 

50 mand including the address and size of the buffer in 
which the data to be sent to the target has been stored 
to the end of the I/O request queue A 202a. 
[0077] I n the S H PT-2 processor 20 1 , a check is made 
to see if the number of commands (in the current ORB 

55 list) belonging to the I/O request queue shown by the 
Current-QUE counter 203a is equal to or larger than the 
number of reserved areas in the prefetch pool allocated 
to the I/O request queue. If it is equal to or less than the 
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number of reserved areas, an ORB is formed from the 
write command and linked to the end of the ORB list 
204. The number of commands (in the current ORB list) 
belonging to the I/O request queue shown by the Cur- 
rent-QUE counter 203a is increased by 1 . If the number 5 
in the ORB list is equal to or larger than the number of 
reserved areas, the Current-POOL counter 203e is 
checked. If there is a free area, namely, if the count value 
of the counter 203e is not equal to 0, an ORB is formed 
from the write command and linked to the end of the io 
ORB list 204. The number of commands (in the current 
ORB list) belonging to the I/O request queue shown by 
the Current-QUE counter 203a is increased by 1 and 
the value of the Current-POOL counter is decreased by 

1. 15 

[0078] The Current-POOL counter 203e is checked 
and if there is no free area, the apparatus waits for the 
free area. In the state of Fig. 2. three ORBs have already 
been linked from the request queue A and this number 
is larger than the number 1 of reserved areas. However, 20 
since the value of the Current-POOL counter is equal to 
3, the value in the Current-POOL counter is reduced to 
2 and the number in the ORB list of the Current-QUE 
counter is increased to 4. The ORB for a writing request 
Qa-4 which waited in the request queue can be added 25 
into the ORB list. Even if the ORB is formed, the write 
command corresponding thereto is not deleted from the 
I/O request queue but deleted at a point when a com- 
pletion status is received from the target. 
[0079] When the ORB is inserted into the ORB iist, 30 
the SHPT-2 processor 201 writes it into the doorbell reg- 
ister 101a of the target through the 1394 interface or 
writes an address of a new ORB into the ORB pointer 
101b. 

[0080] The dispatcher 1 02 extracts a pointer from the 35 
free reference list 104, stores a command of the ORB 
into a free area in the prefetch pool 1 03 indicated by the 
pointer, and connects the pointer to the end of the ref- 
erence queue in accordance with a Queue! D field (in 
this case, it indicates the reference queue A 105a) of *o 
the relevant ORB. The execution agent 1 06 sequentially 
executes the commands in the prefetch pool that is re- 
ferred to by the reference queue. That is, the contents 
in the buffer shown by the write command are written 
into the buffer prepared by the client of the target. When 45 
the process of the command is completed, the execution 
agent writes the status block in which the SHPT-2 status 
indicates "completion" into the status FIFO 205 of the 
initiator. 

[0081] The SHPT-2 processor 201 processes the sta- 50 
tus blocks written into the status FIFO from the head. 
That is, if the SHPT-2 status indicates "completion**, the 
ORB corresponding to the status block is removed from 
the ORB list and, at the same time, the corresponding 
write command in the I/O request queue is deleted. In 55 
this instance, a check is made to see if the number of 
commands (in the current ORB list) belonging to the I/ 
O request queue shown by the Current-QUE counter 



203a exceeds the number of reserved areas in the 
prefetch pool allocated to the I/O request queue. If NO, 
the number of commands (in the current ORB list) 
shown by the Current-QUE counter 203a is reduced by 
1. When the number of commands in the ORB list ex- 
ceeds the number of reserved areas, the count value of 
the Current-POOL counter 203e is increased by 1. The 
number of commands (in the current ORB list) shown 
by the Current-QUE counter 203a is decreased by 1. 
[0082] The above procedure is substantially similar to 
that of the read command. However, the read command 
is not processed so long as the data to be read out is 
not generated in the target. Therefore, the read com- 
mand ORB issued from the initiator is stored into the 
prefetch pool 103 and queued and held in the reference 
queue B 105b until the data to be read out is generated. 
[0083] When the initiator is the host computer and the 
target is the printer, to send the print data from the host 
computer to the printer, it is sent from a printer driver as 
a client of the initiator to the rasterizer as a client of the 
target by using the write command. When the host com- 
puter requests information showing the construction 
and status of the printer, a command (command at the 
client level) indicative of such a fact is transmitted as a 
write command to the printer. The (client of the) printer 
which received the write command sends the requested 
data to the host computer by using the read command 
stored in the prefetch pool and queued in the reference 
queue. Further, in a case such that an error occurs in 
the printer, the client of the printer can spontaneously 
send error information to the host computer by using the 
read command stored in the prefetch pool and queued 
in the reference queue. Therefore, while the host com- 
puter is connected to the printer, it issues at least one 
read ORB to the printer for the purpose of operation. 
Further, to always allow the read command to be stored 
in the prefetch pool and queued in the reference queue, 
it is desirable to issue at least two read ORBs to the 
printer. 

[0084] As for the ORB list 204 in Fig. 2, the ORBs are 
not always sequentially deleted from the head. For ex- 
ample, there is also a case where ORB T4 (command 
Qb-1) directed to the reference queue B 105b is com- 
pleted and deleted prior to ORB T3 (command Qa-2) 
directed to the reference queue A 105a. Therefore, 
there is no link destination of ORB T3 (command Qa-2). 
In this case, since the pointers to ORB T3 (command 
Qa-2) and ORB T5 (command Qa-3) have already been 
sent to the target at the time of processing of ORB T4 
(command Qb-1 ), there is no need to re-connect the link 
destination on the ORB list. Even if the ORB list is 
cleared due to an error or the like, since the correspond- 
ing command remains in the I/O request queue, an error 
recovering process, which will be explained hereinlater, 
can be also normally performed. 
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<Recovery (initiator) of error> 



[0085] As already described above, in SBP-2, the 
connection between the initiator and the target is dis- 
connected by the bus reset due to an abnormality (error) 
on the network. Therefore, in SHPT-2. a procedure to 
recover the status lost by the bus reset is determined. 
[0086] When the bus resetting process is finished af- 
ter the bus reset occurred due to an error or the like on 
the network, the initiator deletes all of the ORBs from 
the ORB list in accordance with the regulations of SBP- 
2. Each I/O request queue is not reset even if the bus 
reset occurred. 

[0087] After the connection is reset, the initiator newly 
forms an ORB from the contents of those queues with 
reference to the I/O request queue and issues it to the 
target. In this instance, by designating again the value 
in the "SeqJD" field allocated to the corresponding 
command at the time of formation of the ORB, the status 
just before the bus reset can be reconstructed. 



above. A processing procedure of the command and 
status in the initiator and target will now be described. 

<Data transfer request by client of initiator 



<Recovery (target) of error> 

[0088] Although the initiator can return the status to 
the status just before the bus reset merely by recovering 
the ORB list, since the target performs the reading/writ- 
ing operation for the buffer in response to the read/write 
command, if the bus reset occurs during the reading/ 
writing operation, its procedure has to be continued after 
the recovery. Therefore, the execution agent of the tar- 
get stores the "SeqJD" field of the command which is 
referred to by each reference queue and is being proc- 
essed and the position in the buffer during the process 
every reference queue. 

[0089] For example, in the case where the initiator is- 
sues the read ORB and the target processes it by the 
execution agent, the execution agent 1 06 reads out the 
"SeqJD" field of the read command ORB which is proc- 
essed from now on before the execution and stores it 
as a sequence identifier (Sequenceidentifier). When da- 
ta is written into the buffer of the client, the address in 
the buffer in which data is being written at present is con- 
tinuously updated as an execution pointer (Nextex- 
ecpointer). Those areas are assured in the memory area 
which is not erased by the bus reset. 
[0090] Since the initiator issues an ORB again after 
completion of the bus reset, if the "SeqJD" field of the 
ORB which has been stored in the prefetch pool and is 
referred to at the head of the reference queue is older 
than the stored sequence identifier, the process of this 
ORB has already been completed, so that the execution 
agent returns the completion status. If both of them co- 
incide, the writing operation is continued from the ad- 
dress indicated by Nextexecpointer. 
[0091] The recovery is also similarly performed with 
respect to the write command. 

[0092] The command and status which are used in the 
printing system of the embodiment have been described 



[0093] Fig. 3 shows a procedure when data is trans- 
mitted or requested to the target from a printer driver or 
the like as a client of the initiator. 

[0094] When a data transmission event occurs (step 
10 S1301), whether the command which is necessary for 
it is the write command or the read command is discrim- 
inated (step S1 302). If it is the write command, whether 
there is a data transfer buffer for it or not is discriminated 
(step S1303). Whether the transmission data to be sent 
15 to the target has been prepared or not is discriminated 
(step S1304). If all of them have been prepared, the 
write command is formed by giving necessary argu- 
ments such as address, size, and the like of the buffer 
(step S1305). A write function is called (step S1306). 
20 [0095] If it is determined that the necessary command 
is the read command, whether there is a transfer buffer 
to receive the data is discriminated (step S 1 307). If YES, 
the read command is formed by sending the necessary 
arguments such as address, size, and the like of the 
25 buffer (step S1308). The read function is called (step 
S1309). 

[0096] For example, when the data transmission 
event is a transmission of the print data to the printer, a 
command at the client level and data such as a PDL are 

30 prepared in the buffer and the write command is formed. 
If the data transmission event is the reading operation 
to read out the status from the printer, a command at the 
client level indicative of such a fact is prepared and the 
write command is formed. At the same time, it is neces- 

35 sary to form the read command to receive data from the 
target. Prior to performing a series of data exchange 
with the target, the client of the initiator issues several 
read commands. 

[0097] Fig. 4 shows a processing procedure when the 
40 client of the initiator receives an end-of-process notice 
from a lower layer, namely, the layer of SHPT-2. First, 
whether the finished process is the reading process or 
the writing process is discriminated (step S1401). If it is 
the writing process, the used data buffer is released 
4 5 (step S1402). If it is the reading process, since the end 
of the process denotes the completion of the data re- 
ception, the process corresponding to the received data 
is performed (step S1403). The data buffer is released 
(step S1404). 

50 

<Process by SHPT-2 processor of initiator 

[0098] Figs. 5A to 5C and 6 show processing proce- 
dures by the SHPT-2 processor of the initiator. 
55 [0099] Figs. 5A and 5B show the contents of a write 
function and a read function which are called by the cli- 
ent, respectively. In the write function, when the client 
issues a connecting request and is connected, a con- 
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nection handle given by the SHPT-2 processor is sent 
as an argument to the client, and on the basis of the ID 
of the I/O request queue corresponding to the connec- 
tion handle, the write command is added into the I/O re- 
quest queue. In the read function as well, in a manner 5 
similar to the above, when the client issues a connecting 
request and is connected, the connection handle given 
by the SHPT-2 processor is sent as an argument to the 
client. On the basis of the ID of the I/O request queue 
corresponding to the connection handle, the read com- 10 
mand is added into the I/O request queue. The com- 
mands queued in the I/O request queues respectively 
are, after that, sent to the reference queues shown by 
"QueuelDI" and "QueuelD2" given by the statuses of the 
connection command on the target side, respectively. is 

(I/O request queue management) 

[0100] Fig. 5C shows a managing procedure of each 
I/O request queue. Those procedures can be independ- 20 
ently performed by a thread schedule by one thread in 
each I/O request queue. Or, all of the I/O request queues 
can be executed in a single thread by independently 
scheduling them in a manner such that the management 
of one I/O request queue is not blocked by the opera- 25 
tions of the other I/O request queues. Or, a combination 
of those methods can be also used. Fig. 5C shows a 
management of one I/O request queue. The manage- 
ment of the I/O request queue is performed every I/O 
request queue. 30 
[01 01 ] First, whether there is a non-ORB command in 
the I/O request queue or not is discriminated (step 
S1601). If YES, a check is made to see if the count value 
of the Current-QUE counter showing the number of 
commands (in the current ORB list) belonging to the I/ 35 
O request queue is smaller than the number of reserved 
areas in the prefetch pool allocated to the I/O request 
queue (step S1602). If YES, step S1605 follows. If the 
count value is equal to or larger than the number of re- 
served areas, step S1604 follows. In step S1604, the *o 
count value of the Current-POOL counter is decreased 
by 1 if the count value of the Current-POOL counter for 
the prefetch pool is larger than 0 (step S1603). Subse- 
quently, 1 is added to the count value of the Current- 
QUE counter (step S1 605). An ORB is formed by adding 45 
the sequence ID (SeqJD) and SHPT-2 command 
(Function) on the basis of the non-ORB command at the 
head stored in the I/O request queue (step S1606). 
[01 02] The ORB formed in this rnanneris included into 
the ORB list (step S1607) and written into the doorbell 50 
of the target or the address of the ORB is written into 
the ORB pointer (step S1608). In this manner, the ORB 
is formed from the command in the I/O request queue. 

(Process for status block) ss 

[01 03) Fig. 6 shows a processing procedure when the 
status block is received from the target. When the status 



block of the process completion for the ORB is received, 
the corresponding ORB is deleted from the ORB list 
(step S1701). The I/O request queue in which the com- 
mand for the corresponding ORB has been queued is 
selected (step S1702). Whether the count value of the 
Current-QUE counter showing the number of com- 
mands (in the current ORB list) belonging to the selected 
I/O request queue is equal to or less than the number 
of reserved areas in the prefetch pool allocated to the 1/ 
O request queue or not is discriminated (step S1703). 
If the count value is equal to or less than the number of 
reserved areas, step S1704 follows. If it is larger than 
the number of reserved areas, step S1705 follows. In 
step S 1 704, the count value of the Current-POOL coun- 
ter for the prefetch pool is increased by 1 . In step S1705, 
subsequently, the count value of the Current-QUE coun- 
ter showing the number of commands (in the current 
ORB list) belonging to the selected I/O request queue 
is decreased by 1. Finally, the end of process is notified 
to the client corresponding to the selected I/O request 
queue (step S1706). The client receives this notice and 
executes the processes of Fig. 4. 

(Error recovering process) 

[01 04] The ordinary processes in the SHPT-2 proces- 
sor have been mentioned above. A procedure for recov- 
ering after the bus reset or the like will now be described 
with reference to Fig. 18. When the bus reset occurs 
and the connection between the target and the SBP-2 
connection is disconnected, the connection of SBP-2 
has to be newly reset. 

[0105] First, a linking process of the new ORB is in- 
termitted (step S1801) and the ORB list is cancelled 
(step S1802). After that, a re-connection command of 
the SBP-2 connection is issued (step S1803) and 
whether the connection has been established or not is 
discriminated (step S1804). If the connection is estab- 
lished again, the corresponding ORB is sequentially 
formed from the command at the head in each I/O re- 
quest queue (step S1805). In this instance, the same ID 
as that added to the command before the bus reset is 
given to the "SeqJD" field of each ORB. The formed 
ORB is linked to the ORB list (step S1806). The address 
is written into the ORB pointer (step S1807), thereby no- 
tifying the target of the generation of the ORB. 
[01 06] When a predetermined time elapses in a state 
where the connection cannot be established again (step 
S1808), all of the commands in each I/O request queue 
are cancelled (step S1809) and an error is informed to 
the client (step S1810). The processing routine is fin- 
ished. By the above procedure, the SBP-2 connection 
with the target is newly established after the reset and 
the ORB list just before the reset can be recovered. 

< Processes by target> 

[0107] Figs. 19 and 20 show processing procedures 
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by the target which received the ORB. 
(Processes by the fetch agent) 

[0108] One fetch agent is prepared for one SBP-2 
connection. The fetch agent fetches the ORB when the 
writing operation is performed to the doorbell register or 
ORB pointer. First, the apparatus waits until the writing 
operation is performed to the doorbell register or ORB 
pointer (step S1901). When it is done, a check is made 
to see if the apparatus has been activated by the writing 
to the doorbell register (step S 1902). If the apparatus is 
activated by the writing to the ORB pointer instead of 
the writing to the doorbell register, step S1903 follows. 
If the writing is performed to the doorbell register, a test 
is made to see if a "Next_ORB" field of the ORB desig- 
nated by the ORB pointer is NULL (there is no subse- 
quent ORB) (step S1907). If it is NULL, the processing 
routine is returned to step S1901. 
[0109] If it is not NULL, step S1908 follows and the 
value in the "Next. ORB" field of the ORB designated by 
the current ORB pointer is written into the ORB pointer 
and updated (step S1908). The processing routine ad- 
vances to step S1903. 

[0110] If the address of the ORB to be processed is 
obtained in the ORB pointer as mentioned above, the 
ORB is read out from the address (step S1903). The 
pointer indicating the free area in the prefetch pool is 
taken out from the free reference list and the readout 
command ORB is stored into the free area (step S1905). 
[0111] The reference queue in which the command 
should be queued is selected with reference to the 
"QueuelD" field of the ORB (step S1905). The pointer 
extracted from the free reference list is queued to the 
end of the selected reference queue (step S1906). 
[0112] After that, the "Next_ORB" field of the ORB in 
which the queueing process is finished is referred to and 
if its contents indicate NULL, namely, if there is not the 
linked ORB, the processing routine is returned to step 
S 1 90 1 , the next ORB is linked, and the apparatus waits 
until the writing operation is performed to the doorbell 
register or ORB pointer. If there is the linked ORB, the 
value in the "Next_ORB" field of the ORB designated by 
the ORB pointer is written into the ORB pointer and up- 
dated (step S1908). The ORBs linked in the ORB list 
are sequentially stored into the prefetch pool. 
[0113] In this manner, the ORBs in the ORB list are 
stored into the prefetch pool. 

[0114] Processes in steps S1904 to S1906 are the 
same as those described as an ORB dispatcher in Fig. 
1. 

(Execution agent) 

[0115] Fig. 20 shows a procedure of the execution 
agent for each reference queue. Those procedures can 
be performed independently by a thread schedule by 
one thread in each reference queue. Or, all of the refer- 



ence queues can be executed in a single thread by in- 
dependently scheduling them in a manner such that the 
management of one reference queue is not blocked by 
the operations of the other reference queues. Or, a com- 
5 bination of those methods can be also used. Fig. 20 
shows a procedure of the execution agent for one ref- 
erence queue. The procedure of the execution agent for 
each reference queue is performed every reference 
queue. 

10 [011 6] The execution agent first discriminates wheth- 
er the pointer to the command in the prefetch pool exists 
in the reference queue or not (step S2001). The ORB is 
extracted from the prefetch pool (step S2002). The 
above processes are performed by using the pointer in- 

15 dicative of the head of the reference queue. When the 
ORB is read out, a check is made to see if the value in 
the "SeqJD" field of the ORB is smaller than the value 
of a variable Sequenceldentifier held by the execution 
agent (step S2003). Both SeqJD and Sequenceldenti- 

20 fier are finite digit numbers. Therefore, when SeqJD 
and Sequenceldentifier are expressed by n bits, in the 
comparison in step S2003, it is defined that ((2 n - 1) < 0 
(= 2 n )). 

[0117] In the ordinary sequence, 1 is added to Se- 
25 quenceldentifier after completion of the process of one 
ORB as will be explained hereinlater. Sequenceldentifi- 
er and SeqJD of the ORB are set to the same digit 
number and SeqJD is also added by 1 at a time. There- 
fore, when the process is progressing without a trouble, 
30 Sequenceldentifier and SeqJD of the ORB ought to co- 
incide in step S2003. Therefore, when the process nor- 
mally progresses, the processing routine is shifted from 
step S2003 to step S2004. 

[0118] Whether the buffer is ready in the client or not 
35 is discriminated (step S2004). If it is ready, the data of 
a predetermined size from the address in which the val- 
ue of data_descriptor of the ORB and an offset value 
stored in NextexecPointer held in the execution agent 
are added is accessed. The data is transmitted and re- 
40 ceived to/from the buffer prepared by the client (step 
S2005). 

[0119] In case of newly performing the process of the 
ORB, since the offset value is equal to 0, data is read 
out from the head of the buffer indicated by the ORB. In 

45 case of subsequently reading out the buffer from the in- 
termitted location in the buffer which has been read out 
to the halfway, since the offset indicates the subsequent 
address in the buffer, by adding it, the data can be con- 
tinuously read out from the intermitted location in the 

so buffer which has been read out to the halfway. When the 
' data is stored into the buffer, NextexecPointer is updat- 
ed in a manner such that (the value of data_descriptor 
+ offset) indicates the address to be subsequently read 
out (step S2006). Such reading/writing operations are 

55 performed until the size of data reaches the size indicat- 
ed by data„size of the ORB (step S2007). 
[0120] When the processes of one ORB are finished, 
1 is added to Sequenceldentifier and it is updated (step 
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52008) . NextexecPointer (offset) is initialized to 0 (step 

52009) . 

[0121] If the processing routine is finished, a status 
block to notify of the completion of the processes is 
formed (step S2010) and written into the status FIFO 
(step S2011). The end of the process is notified to the 
client of the target (step S2012). At the same time, the 
pointer in the reference queue indicative of the relevant 
command is returned to the free reference list. 
[0122] The case where Seq_ID of the ORB is smaller 
than Sequenceldentifier in step S2003 corresponds to 
the case such that the initiator reproduces the ORB list 
by the procedure of Fig. 18 due to the bus reset or the 
like. For example, with respect to a certain ORB, even 
if the target finished the processes and the value of Se- 
quenceldentifier was also updated, when the bus reset 
occurs at a point when its status block does not reach 
the initiator, the initiator also includes the ORB into the 
ORB list. In this case, the value of Sequenceldentifier of 
the execution agent is larger than SeqJD of the ORB. 
In this case, since the processes of the ORB have al- 
ready been finished, the status block is sent to the initi- 
ator in step S2010 and subsequent steps. 

<Connecting procedure of initiator> 

[0123] Fig. 16 shows a processing procedure for an 
opening request from the client on the initiator side. 
When the opening request from the client is received, a 
check is first made to see if the SBP-2 connection (login 
state) with the target of the connection destination has 
already been established (step S2501). If the SBP-2 
connection has already been established, step S2507 
follows. If the SBP-2 connection is not established yet, 
a login request (SBP-2 connecting request) is issued to 
the target (step S2502). Whether the login has succeed- 
ed or not is discriminated (step S2503). When the login 
fails, step S251 3 follows, an error code is set to a return 
value, and the processing routine is returned. When the 
login succeeds, an I/O request queue in which QueuelD 
is equal to 0 is formed and a query command is issued 
thereto (step S2504). Subsequently, whether the query 
command has succeeded or not is discriminated (step 
S2505). If it fails, step S251 2 follows and a logout is ex- 
ecuted. After that, step S251 3 follows. If the query com- 
mand succeeds, the Current-POOL counter is set on the 
basis of "Init.POOL" of the status block for the query 
command. At this time, since the I/O request queue in 
which QueuelD corresponds to 0 has already been tac- 
itly formed, one or more areas are set as reserved areas 
of the I/O request queue in which QueuelD corresponds 
to 0 and the remaining areas are set into the Current- 
POOL counter (step S2506). 

[0124] Further, step S2507 follows and a desired 
ServicelD and Mode are designated for the I/O request 
queue in which QueuelD corresponds to 0 and the con- 
nection command is queued (step S2507). At the time 
of connection, 1" bit is set to 1 in case of obtaining an 



increase amount of the prefetch pool for the target. 
Whether the connection command has succeeded or 
hot is discriminated (step S2508). If it fails, a check is 
made in step S2511 to see if another I/O request queue 

5 except for the queue corresponding to QueuelDO which 
is tacitly prepared is already present. If it is absent, a 
logout from the target is performed, namely, SBP-2 is 
disconnected (step S2512) and step S251 3 follows. If it 
is present, step S2513 follows without performing the 

10 logout. When the connection command succeeds, a 
new I/O request queue is formed in correspondence to 
Queue I Dl and QueuelD2 of the status block. After that, 
a handle for allowing the client to specify this connection 
is made correspond. One or more reserved areas are 

*5 set for each queue on the basis of the sum of the value 
in a PooMnc field of the status block and the value in 
the current Current-POOL register and the value in the 
Current-POOL register is updated by the number of re- 
maining areas (step S2509). A handle which was made 

20 correspond to the I/O request queue formed finally is set 
to the return value (step S2510) and returned to the cli- 
ent on the calling source side. 

<Connecting procedure of target> 

25 

[0125] Fig. 17 shows a processing procedure on the 
target side corresponding to the processing procedure 
for the opening request from the client on the initiator 
side in Fig. 16. 

30 [0126] The target first waits for the arrival of a login 
request (step S2601). 

[0127] When the login request is received, the target 
performs a confirmation of the ID of the initiator, a for- 
mation of a login descriptor, and the like as operations 

35 specified in SBP-2. The target also forms a prefetch pool 
having at least one entry and forms a free reference list 
as a list of the pointers for the entries in the prefetch 
pool. A pointer for the reference queue in which Queue- 
ID is equal to 0 and the like are also prepared (step 

40 S2602). After completion of the above preparation, the 
target returns a login response specified in SBP-2 to the 
initiator (step S2603). Subsequently, the target waits for 
the arrival of the query command (step S2604). When 
the query command is received, a size of formed 

45 prefetch pool is added into the "lnit_POOL" field and a 
status block in response to the query command is sent 
(step S2605). The preparation for the communication by 
SHPT-2 can be made in this manner. 
[0128] A loop in step S261 0 and subsequent steps re- 

50 lates to a processing procedure of the execution agent 
based on the reference queue of QueuelDO. Whether 
the command is the connection command or not is dis- 
criminated in step S2606. If it is not the connection com- 
mand, the processes of other commands are performed 

55 in step S2609. The processing routine is returned to step 
S261 0. If it is the connection command, pointers for one 
or two reference queues or the like are formed in ac- 
cordance with the mode designated in the Mode field. 
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At this time, if "i" bit of the connection command is equal 
to 1 , entries of the number that is equal to or larger than 
the number of formed reference queues are added into 
the prefetch queue (step S2607). The IDs of the formed 
reference queues and the number of entries added into 
the prefetch queue are returned to the initiator by the 
status block for the connection command (step S2608). 
The communication between the clients can be per- 
formed by using the reference queues formed after that. 

<Connection end procedure of initiator* 

[0129] "Fig. 21 shows a processing procedure for a 
closing request from the client on the initiator side. When 
the closing request is received, a disconnection com- 
mand is first issued. When the user wants to disconnect 
after the command which has already been queued in 
the I/O request queue of relevant QueuelD is finished, 
the "QueuelD" field of the disconnection command is set 
to relevant QueuelDO. When the user wants to discon- 
nect irrespective of the queued command, the discon- 
nection command is issued to QueuelD. In this case, a 
queue to be disconnected is designated in the "Queue- 
IDI" and "QueuelD2" fields (step S2701). The apparatus 
subsequently waits for completion of the disconnection 
command (step S2702). After completion of the discon- 
nection command, if the ORBs for the disconnected 
queues remain in the current ORB list, all of them are 
invalidated by the control field specified by SBP-2. The 
I/O request queue formed at the time of connection is 
released. The count value of the Current-POOl counter 
is increased by a value corresponding to the number of 
ORBs in the current ORB list shown by the count value 
of the Current-QUE counter of the I/O request queue 
and is, further, reduced by a value corresponding to the 
increased value in the prefetch pool received upon con- 
nection (step S2703). A check is further made to see if 
another I/O request queue except for the queue of 
QueuelDO that is tacitly prepared is already present 
(step S2704). If it is absent, a logout from the target is 
performed, namely, SBP-2 is disconnected (step 
S2705). The handle allocated upon connection is re- 
leased. The processing routine is returned. 

<Connection end procedure of target> 



[01 30] Fig. 22 shows a disconnection processing pro- 
cedure of the target. This procedure is located in step 
S2609in Fig. 17. First, whether the command is the dis- 
connection command or not is discriminated (step 
S2801 ). If it is not the disconnection command, process- 
es of other commands are further performed (step 
S2807). If it is the disconnection command, among the 
commands referred to by the reference queue serving 
as a target of the disconnection, if there is a command 
which is being executed except for the disconnection 
command, the execution of such a command is stopped 
(step S2802). After the execution is stopped, if there are 



status blocks which are not sent yet among the status 
blocks for the commands other than the disconnection 
command referred to by the reference queue, all of them 
are sent (step S2803). After that, the status block in re- 

5 sponse to the disconnection command is returned (step 
S2804). At this time point, all of the un-processed point- 
ers remaining in the reference queue are returned to the 
free reference list (step S2805). If the prefetch pool was 
increased upon connection, the added amount is de- 

10 creased and the pointers in the free reference list which 
is referred to are deleted by the decreased amount. Fur- 
ther, the pointers or the like for the reference queues are 
also deleted (step S2806). The processing routine is re- 
turned. 

15 [0131] As shown in Figs. 7A and 7B, a field of a queue 
identifier such as QueuelD is provided for the ORB. 
Therefore, the SHPT-2 processor and ORB dispatcher 
identify the queue identifier and each of them independ- 
ently executes the process, namely, performs the for- 
20 mation and process of the ORB every queue, so that a 
multiconnection (channel) by a plurality of queues can 
be realized. In this case, even in one piece of equipment, 
an asynchronous communication can be performed 
every client by allocating one connection (channel) to 
25 each of a plurality of clients included there. 

[0132] Therefore, for example, in case of a digital hy- 
brid apparatus, if an application serving as a client is 
provided for each of the scanners and printers which the 
hybrid apparatus has. the hybrid apparatus can be used 
jo by the host computer connected thereto as if each func- 
tion were independent equipment. As shown in the flow- 
charts, since the management of each queue and the 
execution agent are logically independent processes, 
the multiconnection (channel) can be easily realized. 
35 [0133] By using two queues which are identified by 
QueuelD for one connection, a data exchange can be 
performed bidirectional^ between the initiator and the 
target by a simple control procedure. That is, the initiator 
can send desired data to the target anytime. The target 
40 can read out the data sent from the initiator in accord- 
ance with circumstances of the target itself. So long as 
the initiator is prepared, the target can send data to the 
initiator any time irrespective of a spontaneous purpose 
or a request from the initiator. Even if the bus reset oc- 
45 curs, the continuation of the processes from the inter- 
mitted state just before the bus reset can be guaranteed. 
[0134] Further, the initiator dynamically performs the 
allocation of the whole command pool area of the target 
on the multiplex path by the queue, so that a communi- 
50 eating efficiency and a resource using efficiency of the 
target are improved. Since the command pool area of 
the target is increased or decreased in accordance with 
the number of. queues which are used for connection, 
the resource using efficiency of the target is improved. 

55 

(Other embodiments) 



[0135] The invention can be applied to a system con- 
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structed by a plurality of equipment (for example, a host 
computer, interface equipment, a reader, a printer, and 
the like) or can be also applied to an apparatus (for ex- 
ample, a copying apparatus, a facsimile apparatus, or 
the like) comprising one piece of equipment. 
[0136] As for the initiator, the object of the invention 
is also accomplished by a method whereby a storage 
medium in which program codes of the procedures 
shown in Figs. 3 to 6, 16, 18, and 21 have been recorded 
is supplied to a computer and the computer (or a CPU 
or an MPU) reads out and executes the program codes 
stored in the storage medium. As for the target as well, 
the object of the invention can be also accomplished by 
a method whereby a storage medium in which program 
codes of the procedures shown in Figs. 17, 19, 20, and 
22 have been recorded is supplied to a computer and 
the computer (or a CPU or an MPU) reads out and ex- 
ecutes the program codes stored in the storage medi- 
um. 

[0137] In this case, the program codes themselves 
read out from the storage medium realize the functions 
of the foregoing embodiment and the storage medium 
in which the program codes have been stored con- 
structs the invention. 

[0138] As a storage medium to supply the program 
codes, for example, a floppy disk, a hard disk, an optical 
disk, a magnetooptic disk, a CD-ROM, a CD-R, a mag- 
netic tape, a non-volatile memory card, an ROM, or the 
like can be used. 

[0139] The invention incorporates not only a case 
where the functions of the embodiment mentioned 
above are realized by executing the read-out program 
codes by a computer but also a case where the functions 
of the embodiment mentioned above are realized by a 
method whereby the OS (Operating System) or the like 
which operates on the computer executes a part or all 
of the actual processes on the basis of instructions of 
the program codes and the functions of the embodiment 
mentioned above are realized by those processes. 
[0140] Further, the invention also incorporates a case 
where the program codes read out from the storage me- 
dium are written into a memory equipped for a function 
expanding board inserted into the computer or a func- 
tion expanding unit connected to the computer and, after 
that, a CPU or the like equipped for the function expand- 
ing board or function expanding unit executes a part or 
all of the actual processes on the basis of instructions 
of the program codes, and the functions of the embod- 
iment mentioned above are realized by those process- 
es. 

[0141] A main apparatus serving as an initiator by ex- 
ecuting the program codes read out from the storage 
medium is not limited to the computer but any data trans- 
fer equipment can be used so long as it has a login ability 
of SBP-2. 

[0142] As for the target, pipeline processes can be re- 
alized by using a plurality of reference queues, for ex- 
ample, by storing a print job into a first reference queue. 



storing a read command to confirm a status of the target 
into a second queue, and storing a finisher control com- 
mand into a third queue, and after completion of the 
printing based on a print job, a next print job can be 
5 stored into the first reference queue prior to finishing the 
execution of the function by the finisher. 

(Second embodiment) 

10 [0143] Although the first embodiment has been con- 
structed in a manner such that the capacity of the 
prefetch pool upon disconnection is decreased by the 
increased amount at the time of the corresponding con- 
nection, the initiator can instruct the decrease amount 

15 upon disconnection. In this case, for the disconnection 
command ORB in Fig. 11, a **POOL_Dec" field 309f is 
provided and an amount of prefetch pool to be released 
to the target is designated in this field when the initiator 
issues the disconnection command as shown in Fig. 23. 

20 The command is issued in step S2701 in Fig. 21. The 
target decreases the prefetch pool by the amount des- 
ignated by the "POOL_Dec" field in step S2806 in Fig. 
22. 

[0144] Even in this embodiment, the following effects 
25 are obtained in a manner similar to the first embodiment. 
The SHPT-2 processor and ORB dispatcher identify the 
queue identifier and each of them independently exe- 
cutes the process, namely, performs the formation and 
process of the ORB every queue, so that a multiconnec- 
30 tion (channel) by a plurality of queues can be realized. 
In this case, even in one piece of equipment, an asyn- 
chronous communication can be performed every client 
by allocating one connection (channel) to each of a plu- 
rality of clients included therein. 
35 [0145] Therefore, for example, in case of a digital hy- 
brid apparatus, if an application serving as a client is 
provided for each of the scanners and printers which the 
hybrid apparatus has, the hybrid apparatus can be used 
by the host computer connected thereto as if each func- 
4 0 tion were independent equipment. As shown in the flow- 
charts, since the management of each queue and the 
execution agent are logically independent processes, 
the multiconnection (channel) can be easily realized. 
[0146] By using two queues which are identified by 
45 QueuelD for one connection, a data exchange can be 
performed bidirectionally between the initiator and the 
target by a simple control procedure. That is, the initiator 
can send desired data to the target anytime. The target 
can read out the data sent from the initiator in accord- 
50 ance with circumstances of the target itself. So long as 
the initiator is prepared, the target can send data to the 
initiator any time irrespective of a spontaneous purpose 
or a request from the initiator. Even if the bus reset oc- 
curs, the continuation of the processes from the inter- 
55 mitted state just before the bus reset can be guaranteed. 
[0147] Further, the initiator dynamically performs the 
allocation of the whole command pool area of the target 
on the multiplex path by the queue, so that a communi- 
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eating efficiency and a resource using efficiency of the 
target are improved. Since the command pool area of 
the target is increased or decreased in accordance with 
the number of queues which are used for connection, 
the resource using efficiency of the target is improved. 5 

(Third embodiment) 

[0148] Although the first embodiment has been con- 
structed in a manner such that the initiator designates 10 
only a discrimination about whether the increase in the 
prefetch pool is requested or not by T bit in the connec- 
tion command, the initiator can also request the in- 
crease by designating the increase number. In this case, 
it is sufficient to increase the number of bits in the "i" 15 
field in the connection command in Fig. 1 0 and indicate 
the increase number. Further, although the first embod- 
iment has been constructed in a manner such that the 
reserved areas corresponding to the prefetch pool for 
the queue on the initiator side are set only at the time of 20 
the connection, the reserved areas can be also in- 
creased or decreased anytime other than the time of the 
connection. In this case, the increased amount of the 
reserved areas is set so as not to exceed the value in 
the Current- POOL counter, the number of reserved ar- 25 
eas is increased and the count value in the Current- 
POOL counter is decreased within such a range. To de- 
crease it, when the number of ORBs (in the current ORB 
list) which is shown by the count value in the Current- 
QUE counter and belongs to the relevant queue is lower 30 
than the number of reserved areas, the count value can 
be decreased in a range such that a difference between 
the number of ORBs and the number of reserved areas 
is set to an upper limit and a range in which the number 
of reserved areas after the reduction is equal to or larger 35 
than 1 in such a range. In this case, the number of re- 
served areas is reduced within such a range and the 
count value in the Current-POOL counter is increased. 
[01 49] Even in this embodiment, the following effects 
are obtained in a manner similar to those in the first em- 40 
bodiment. The SHPT-2 processor and ORB dispatcher 
identify the queue identifier and each of them independ- 
ently executes the process, namely, performs the for- 
mation and process of the ORB every queue, so that a 
multiconnection (channel) by a plurality of queues can 45 
be realized. In this case, even in one piece of equipment, 
an asynchronous communication can be performed 
every client by allocating one connection (channel) to 
each of a plurality of clients included there. 
[01 50] Therefore, for example, in case of a digital hy- 50 
brid apparatus, if an application serving as a client is 
provided for each of the scanners and printers which the 
hybrid apparatus has, the hybrid apparatus can be used 
by the host computer connected thereto as if each func- 
tion were independent equipment. As shown in the flow- 55 
charts, since the management of each queue and the 
execution agent are logically independent processes, 
the multiconnection (channel) can be easily realized. 



[0151] By using two queues which are identified by 
QueuelD for one connection, a data exchange can be 
performed bidirectionally between the initiator and the 
target by a simple control procedure. That is, the initiator 
can send desired data to the target at any time. The tar- 
get can read out the data sent from the initiator in ac- 
cordance with circumstances of the target itself. So long 
as the initiator is prepared, the target can send data to 
the initiator any time irrespective of a spontaneous pur- 
pose or a request from the initiator. Even if the bus reset 
occurs, the continuation of the processes from the inter- 
mitted state just before the bus reset can be guaranteed. 
[0152] Further, the initiator dynamically performs the 
allocation of the whole command pool area of the target 
on the multiplex path by the queue, so that a communi- 
cating efficiency and a resource using efficiency of the 
target are improved. Since the command pool area of 
the target is increased or decreased in accordance with 
the number of queues which are used for connection, 
the resource using efficiency of the target is improved. 

(Fourth embodiment) 



[0153] In the embodiment, although the increase or 
decrease of the prefetch pool is designated by the "i" bit 
309e of the connection command (Fig. 10) and the dis- 
connection command (Fig. 23), the rt POOL_Dec" field, 
or the like or the value designated in the "POOLJnc" 
field in the connection status (Fig. 14) is used, independ- 
ent commands for increasing or decreasing the prefetch 
pool can be also provided in place of them. 
[0154] Fig. 25 shows a format of a prefetch pool ca- 
pacity changing command (function code = C3H). In Fig. 
25, a "delta" field 309g shows a numerical value with a 
sign of a format of a complement of 2. If this field is pos- 
itive, the increase in the prefetch pool is instructed to 
the target. If it is negative, the decrease in the prefetch 
pool is instructed to the target. The target actually in- 
creases or decreases the prefetch pool in response to 
the instruction of the command. 

[01 55] In case of using the command, when the open- 
ing request from the client of the initiator is processed, 
if the increase in the prefetch pool is necessary, prior to 
step S2507 in Fig. 16, the initiator issues a prefetch pool 
changing command, thereby increasing the prefetch 
pool. Since the target has already received the prefetch 
pool changing command separately if necessary before 
step S2607 in Fig. 17, only the pointers or the like for 
the reference queues are formed. When the closing re- 
quest from the client of the initiator is processed, after 
the disconnection command succeeds (step S2703), 
the prefetch pool capacity changing command is issued, 
thereby reducing the prefetch pool. Since the prefetch 
pool capacity changing command ought to be issued 
from the initiator later, in the process (Fig. 22) of the dis- 
connection command, only the pointers or the like which 
are used for the reference queues are deleted and the 
prefetch pool is not decreased in step S2806. 
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[01 56] Even in this embodiment, the following effects 
are obtained in a manner similar to those in the first em- 
bodiment. The SHPT-2 processor and ORB dispatcher 
identify the queue identifier and each of them independ- 
ently executes the process, namely, performs the for- 5 
mation and process of the ORB every queue, so that a 
multiconnection (channel) by a plurality of queues can 
be realized. In this case, even in one piece of equipment, 
an asynchronous communication can be performed 
every client by allocating one connection (channel) to 10 
each of a plurality of clients included there. 
[01 57] Therefore, for example, in case of a digital hy- 
brid apparatus, if an application serving as a client is 
provided for each of the scanners and printers which the 
hybrid apparatus has, the hybrid apparatus can be used f 5 
by the host computer connected thereto as if each func- 
tion were independent equipment. As shown in the flow- 
charts, since the management of each queue and the 
execution agent are logically independent processes, 
the multiconnection (channel) can be easily realized. 20 
[0158] By using two queues which are identified by 
QueuelD for one connection, a data exchange can be 
performed bidirectionally between the initiator and the 
target by a simple control procedure. That is. the initiator 
can send desired data to the target at any time. The tar- 25 
get can read out the data sent from the initiator in ac- 
cordance with circumstances of the target itself. So long 
as the initiator is prepared, the target can send data to 
the initiator any time irrespective of a spontaneous pur- 
pose or a request from the initiator. Even if the bus reset 30 
occurs, the continuation of the processes from the inter- 
mitted state just before the bus reset can be guaranteed. 
[0159] Further, the initiator dynamically performs the 
allocation of the whole command pool area of the target 
on the multiplex path by the queue, so that a communi- 35 
eating efficiency and a resource using efficiency of the 
target are improved. Since the command pool area of 
the target is increased or decreased in accordance with 
the number of queues which are used for connection, 
the resource using efficiency of the target is improved. *o 
[01 60] According to the invention as described above, 
an asynchronous bidirectional communication can be 
performed and its multichannel can be realized by one 
login between the initiator and the target and the re- 
sources such as processes and memory which are nec- 45 
essary for data exchange can be efficiently used. 
[0161] Since the IEEE 1394 interface is used, in the 
data transfer to the target side, the target can read out 
the data in accordance with its circumstances and a sit- 
uation such that the initiator is occupied by the data so 
transfer due to the circumstances of the target can be 
prevented. 

[0162] Since the SBP-2 protocol is used, only the 
ORB is queued in the target and the data itself which is 
actually transferred is stored in the initiator for a process 55 
waiting period of time. Thus, a capacity of the memory 
resources of the target can be reduced. 
[0163] By holding the latest processing state, even if 



the bus reset occurs, the process can be restarted from 
the state just before the bus reset after the bus reset, 
and the normal continuation of the processes can be 
guaranteed. 

[01 64] The number of commands which can be trans- 
mitted from the initiator to the target is not managed eve- 
ry queue of the target but is unitarily managed, so that 
the resources can be efficiently used. 
[01 65] By dynamically allocating the whole command 
pool area of the target on the multiplex path due to the 
queues by the initiator, the communicating efficiency 
and the resource using efficiency of the target are im- 
proved. The command pool areas of the target are in- 
creased or decreased in accordance with the number of 
queues which are used for connection. Thus, the re- 
source using efficiency of the target can be improved. 

Claims 

1. A communication control method of issuing com- 
mands from an initiator to a target, thereby allowing 
said target to write orread out data into/from a mem- 
ory area which said initiator has and exchanging the 
data, 

wherein said initiator transmits read and write 
commands for said memory area to said target 
so as not to exceed the total number of com- 
mands which can be held in the target, and 
said target holds the received read and write 
commands, holds references to said com- 
mands by different queues, and individually 
processes them. 

2. A method according to claim 1. wherein the issue 
of the commands from said initiator to said target is 
performed by storing the commands into the mem- 
ory area which said initiator has and reading out the 
commands from the memory area of said initiator 
by said target in accordance with an instruction of 
said initiator. 

3. A method according to claim 1, wherein the total 
number of commands which can be held by said 
target is increased in accordance with an increase 
in the number of said queues. 

4. A method according to claim 3, wherein the total 
number of commands which can be held by said 
target is increased by the number that is equal to or 
larger than the increased number of said queues. 

5. A method according to claim 1, wherein the total 
number of commands which can be held by said 
target is increased in accordance with a command 
parameter of said initiator. 
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6. A method according to claim 1, wherein the total 
number of commands which can be held by said 
target is decreased in accordance with a decrease 
in the number of said queues. 

5 

7. A method according to claim 6, wherein the total 
number of commands which can be held by said 
target is decreased at the time of said decrease in 
the number of said queues by an increased amount 
of the total number of commands which was in- w 
creased in association with the increase in the 
number of said queues and can be held by said tar- 
get' 



8. A method according to claim 6, wherein the total 15 
number of commands which can be held by said 
target is decreased in accordance with a command 
parameter of said initiator. 

9. A method according to claim 1, wherein said target 20 
and said initiator add queue identifiers with respect 
to said write and read commands and independent- 
ly process each of said commands every said 
queue identifier. 

25 

1 0. A method according to claim 1 , wherein said initiator 
allocates the commands of the number for each 
queue so that said target can hold at least one com- 
mand for each of said queues. 

30 

11. A method according to claim 10, wherein said initi- 
ator allocates the commands of the nu mber for each 
queue when the number of queues is increased or 
decreased. 

35 

12. A communication system for issuing commands 
from an initiator to a target, thereby allowing said 
target to write or read out data into/from a memory 
area which said initiator has and exchanging the da- 
ta' 40 

wherein said initiator transmits read and write 
commands for said memory area to said target 
so as not to exceed the total number of com- 
mands which can be held in the target, and 45 
said target holds the received read and write 
commands, holds references to said com- 
mands by different queues, and individually 
processes them. 

50 

13. A system according to claim 12, wherein the issue 
of the commands from said initiator to said target is 
performed by storing the commands into the mem- 
ory area which said initiator has and reading out the 
commands from the memory area of said initiator 55 
by said target in accordance with an instruction of 
said initiator. 



14. A system according to claim 12, wherein the total 
number of commands which can be held by said 
target is increased in accordance with an increase 
in the number of said queues. 

15. A system according to claim 14, wherein the total 
number of commands which can be held by said 
target is increased by the number that is equal to or 
larger than the increased number of said queues. 

16. A system according to claim 11, wherein the total 
number of commands which can be held by said 
target is increased in accordance with a command 
parameter of said initiator. 

17. A system according to claim 12, wherein the total 
number of commands which can be held by said 
target is decreased in accordance with a decrease 
in the number of said queues. 

18. A system according to claim 17, wherein the total 
number of commands which can be held by said 
target is decreased at the time of said decrease in 
the number of said queues by an increased amount 
of the total number of commands which was in- 
creased in association with the increase in the 
number of said queues and can be held by said tar- 
get. 

19. A system according to claim 17, wherein the total 
number of commands which can be held by said 
target is decreased in accordance with a command 
parameter of said initiator. 

20. A system according to claim 12, wherein said target 
and said initiator add queue identifiers with respect 
to said write and read commands and independent- 
ly process each of said commands every said 
queue identifier. 



21. A system according to claim 12, wherein said initi- 
ator allocates the commands of the number for each 
queue so that said target can hold at least one com- 
mand for each of said queues. 

22. A system according to claim 21. wherein said initi- 
ator allocates the commands of the numberfor each 
queue when the number of queues is increased or 
decreased. 

23. A printing apparatus comprising a host apparatus 
and a printer apparatus connected thereto, 

wherein said printer apparatus receives print 
data from said host apparatus and prints and 
outputs on the basis of said print data, and 
said host apparatus receives printer status in- 
formation from said printer apparatus, 
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said host apparatus transmits read and write 
commands for a memory area of said printer 
apparatus to said printer apparatus so as not 
to exceed the total number of commands which 
can be held by said printer apparatus, and 5 
said printer apparatus holds the received read 
and write commands, holds references to said 
commands by different queues, and independ- 
ently processes them. 

10 

24. A communication control method of reading out or 
writing data from/into a memory area in a memory 
frorfi a target connected by a communication, there- 
by exchanging the data to said target, comprising: 

15 

a queueing step of registering the commands 
into a queue in accordance with a request from 
an application; and 

a command forming step of forming commands 
and transmitting said commands to said target 20 
so as not to exceed parameters of the total 
number of commands which were supplied 
from said target and can be held by said target. 

25. A method according to claim 24, wherein in said 25 
command forming step, the commands of the 
number for each queue are allocated so that said 
target can hold at least one command for each of 
said queues. 

30 

26. A print control apparatus for transmitting print data 
to a target and receives status information from said 
target by a communication control method accord- 
ing to claim 24. 

35 

27. A communication control method of reading and 
writing data from/into a memory area which an ini- 
tiator connected by a communication has and ex- 
changing the data to said initiator, comprising: 

40 

a storing step of registering commands from 
said initiator into the memory area of a prede- 
termined capacity; 

a queueing step of registering reference data 

to refer to the commands stored by said storing 45 

step into queues; and 

a sequential executing step of sequentially ex- 
tracting the commands which are referred to by 
said queues and executing said commands. 

50 

28. A method according to claim 27, further comprising: 

a capacity changing step of increasing or de- 
creasing a capacity of the memory area of said 
predetermined capacity in accordance with an 55 
increase or decrease of said queues; and 
a notifying step of notifying the initiator of an 
increased amount. 



29. A method according to claim 28, wherein in said ca- 
pacity changing step, the total number of com- 
mands which can be held by said target is increased 
by the number that is equal to or larger than the in- 
crease number of said queues. 

30. A method according to claim 28, wherein in said ca- 
pacity changing step, the total number of com- 
mands which can be held by said target is increased 
in accordance with a command parameter from said 
initiator. 

31. A method according to claim 28, wherein in said ca- 
pacity changing step, the total number of com- 
mands which can be held by said target is de- 
creased at the time of said decrease in the number 
of said queues by an increased amount of the total 
number of commands which was increased in as- 
sociation with the increase in the number of said 
queues and can be held by said target. 

32. A method according to claim 28, wherein in said ca- 
pacity changing step, the total number of com- 
mands which can be held by said target is de- 
creased in accordance with a command parameter 
of sard initiator. - 

33. A printing apparatus for receiving print data from an 
initiator and transmitting status information to said 
initiator, comprising: 

registering means for registering commands 
from said initiator into a memory area of a pre- 
determined capacity; 

queueing means for registering reference data 
to refer to the commands registered by said 
registering means into queues; and 
sequential executing means for sequentially 
extracting the commands which are referred to 
by said queues and executing said commands. 

34. A host apparatus which is connected to a peripheral 
apparatus having storing means for storing re- 
quests and means for queueing information to refer 
to said requests stored in said storing means into a 
plurality of reference queues, comprising: 

holding means for holding a plurality of request 
queues corresponding to requests from a cli- 
ent; 

managing means for managing the number of 
request queues which can be stored into said 
storing means of said peripheral apparatus; 
and 

means for storing the requests of said queues 
held in said holding means into a list on the ba- 
sis of the number managed in said managing 
means. 
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35. A peripheral apparatus which is connected to a host 
apparatus, comprising: 

storing means for storing requests from said 
host apparatus; 

means for queueing information to refer to the 
requests stored in said storing means into a plu- 
rality of reference queues; and 
means for independently executing the re- 
quests of said reference queues on the basis 
of said referring information. 

36. Anapparatus according to claim 35, wherein 

said peripheral apparatus is a printer, and 
a print job and a finisher control command are 
queued into said plurality of reference queues. 

37. A control method for a host apparatus which is con- 
nected to a peripheral apparatus having storing 
means for storing requests and means for queueing 
information to refer to said requests stored in said 
storing means into a plurality of reference queues, 
comprising the steps of: 

holding a plurality of request queues corre- 
sponding to requests from a client into said 
storing means; and 

storing the requests of said queues held in said 
holding means into a list so as not to exceed 
the number of requests which can be stored in 
said storing means of said peripheral appara- 
tus. 

38. A control method for a peripheral apparatus which 
is connected to a host apparatus, comprising the 
steps of: 

storing requests from said host apparatus into 
storing means; 

queueing information to refer to the requests 
stored in said storing means into a plurality of 
reference queues; and 

independently executing the requests of said 
reference queues on the basis of said referring 
information. 

39. A method according to claim 38, wherein 

said peripheral apparatus is a printer, and 

a print job and a finisher control command are 

queued into said plurality of reference queues. 
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plurality of reference queues, 

wherein said control program comprises the 
steps of: 

holding a plurality of request queues corre- 
sponding to requests from a client into said 
storing means; and 

storing the requests of said queues held in said 
holding means into a list so as not to exceed 
the number of requests which can be stored in 
said storing means of said peripheral appara- 
tus. 

41 . A storage medium which stores a control program 
for a peripheral apparatus which is connected to a 
host apparatus, 

wherein said control program comprises the 
steps of: 

storing requests from said host apparatus into 
storing means; 

queueing information to refer to the requests 
stored in said storing means into a plurality of 
reference queues; and 

independently executing the requests of said 
reference queues on the basis of said referring 
information. 

42. A medium according to claim 41, wherein 

said peripheral apparatus is a printer, and 

a print job and a finisher control command are 

queued into said plurality of reference queues. 

43. A system comprising a host apparatus and a pe- 
ripheral apparatus, wherein 



40. 



A storage medium which stores a control program 
for a host apparatus which is connected to a periph- 
eral apparatus having storing means for storing re- 
quests and means for queueing information to refer 
to said requests stored in said storing means into a 



said host apparatus has holding means for 
holding a plurality of request queues corre- 

40 sponding to requests from a client, managing 

means for managing the number of request 
queues which can be stored into said storing 
means of said peripheral apparatus, and 
means for storing the requests of said queues 

45 held in said holding means into a list on the ba- 

sis of the number managed in said managing 
means, and 

said peripheral apparatus comprises storing 
means for storing requests from said host ap- 

50 paratus, means for queueing information to re- 

fer to the requests stored in said storing means 
into a plurality of reference queues, and means 
for independently executing the requests of 
said reference queues on the basis of said re- 

55 ferring information. 

44. A system according to claim 43, wherein 
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said peripheral apparatus is a printer, and 

a print job and a finisher control command are 

queued into said plurality of reference queues. 
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FIG. 21 
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FIG. 22 
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